ConfigType
ConfigType is a business-friendly packaging catalog that lets you organize tSM configuration into clear, navigable sections (for example: Ordering, Ordering.SDWAN, Ticketing.CustomerTicket, Integrations.SAP). It helps teams quickly find what belongs together, understand who owns it, and scope admin operations (filtering, auditing, backup/restore selections, studio navigation) to a specific area.
ConfigType is intended to group any mix of configuration assets—forms, processes, registers, listings, notifications, widgets, scripts, and other configuration types—under a single “package-like” node.
See also:
Why it matters
- Organization & discoverability — quickly find all assets for a domain/product area.
- Scoped operations — filter, audit, compare, export/restore only what belongs to a given area.
- Lifecycle control — validity windows and tags can help manage configuration over time.
- Clear ownership — make responsibility explicit at the package level (team ownership, stewards, approvals).
How ConfigType is used by configuration entities
All configuration entities in tSM contain a property:
configType(String) — holds the ConfigTypecode.
This makes ConfigType the common “routing key” for:
- UI navigation (grouping and filtering)
- audit views (“who owns what”)
- packaging scope (“what belongs to this area”)
Hierarchical codes
ConfigType code is hierarchical by design.
Rule
A child ConfigType code MUST include the full code of all its parents as a prefix.
- A parent–child relationship is valid only if:
child.code = parent.code + "." + <segment>(or the configured delimiter), and the child explicitly references that parent (seeparentfield below).
Examples
-
cap.ordering-
cap.ordering.catalog -
cap.ordering.forms -
cap.ordering.processes -
cap.ordering.sdwancap.ordering.sdwan.catalogcap.ordering.sdwan.formscap.ordering.sdwan.processes
-
This rule ensures that:
- the hierarchy is readable from the code itself,
- filtering by prefix is reliable (everything under
cap.ordering.*is “Ordering”).
Typical uses
- Separate configuration areas by business domain or product line (e.g.,
cap.ticketing.*,cap.ordering.*,cap.ordering.sdwan.*). - Power admin tooling selections (e.g., “restore only
cap.ordering.*andcap.ticketing.*”). - Navigate large installations in tSM Studio and admin UI by a stable taxonomy.
Reference
ConfigType (attributes)
| Field | Type | Required | Read-only | Description / Notes |
|---|---|---|---|---|
id | UUID | – | – | Identifier (not intended for end-user display). |
code | String | Yes | – | Unique ASCII code (no spaces). Used in references, filters, and tooling. Must be hierarchical (includes parent codes). |
name | String | Yes | – | Human-readable name shown in admin UI. |
description | String | – | – | Longer help text / tool-tip. |
parent | String | – | – | Optional hierarchical parent ConfigType.code. Used to build trees. |
validityFrom/To | Date | – | – | Active window for this config group. |
valid | Bool | – | Yes | Computed from validity; not stored. |
syncMethod | Enum | Yes | – | Declares how configs under this type are deployed between environments (see below). |
ownerUserGroups | List | Yes | – | Owner group(s) responsible for configuration under this ConfigType (code of UserGroup). |
config | Map | – | – | Free-form metadata for admin tooling; keep it lightweight. |
dataTags | List | – | – | Labels for dashboards/filters (e.g., core, pilot, external). |
localizationData | Object | – | – | Translations for name / description. |
auditInfo | Object | – | – | Standard audit metadata. |
syncMethod semantics
MANUAL— default; admins export/import explicitly.NONE— environments diverge intentionally; no cross-env sync.COMPARE— changes originate in test/UAT; deployment uses diff & apply workflows.SYSTEM— platform-critical configs; typically updated with application releases.
End-to-end example: Ordering vs SD-WAN-specific configuration
This example shows how to keep generic Ordering assets under Ordering packages, while placing SD-WAN-specific assets into a dedicated sub-package under Ordering.
ConfigType tree (packages)
| Code | Name | Parent | Owner team | Purpose |
|---|---|---|---|---|
cap.ordering | Ordering | – | Ordering Team | Root for ordering capability configuration. |
cap.ordering.catalog | Ordering / Catalog | cap.ordering | Ordering Team | Shared catalog patterns, generic offerings/templates. |
cap.ordering.forms | Ordering / Forms | cap.ordering | Ordering Team | Generic ordering forms and reusable fragments. |
cap.ordering.processes | Ordering / Processes | cap.ordering | Ordering Team | Generic order lifecycle processes (validation, submission, cancellation). |
cap.ordering.sdwan | Ordering / SD-WAN | cap.ordering | SD-WAN Solution Team | SD-WAN-specific ordering configuration. |
cap.ordering.sdwan.catalog | Ordering / SD-WAN / Catalog | cap.ordering.sdwan | SD-WAN Solution Team | SD-WAN product catalog records and SD-WAN-specific attributes. |
cap.ordering.sdwan.forms | Ordering / SD-WAN / Forms | cap.ordering.sdwan | SD-WAN Solution Team | SD-WAN-specific order capture wizards/forms. |
cap.ordering.sdwan.processes | Ordering / SD-WAN / Processes | cap.ordering.sdwan | SD-WAN Solution Team | SD-WAN-specific orchestration steps in ordering processes. |
How configuration entities are assigned
All relevant entities store configType as the code of the owning package:
| Entity type | Example item | configType | Notes |
|---|---|---|---|
| Catalog record | “Generic Broadband Offer Template” | cap.ordering.catalog | Reused across products. |
| Form | “Generic Order Header” | cap.ordering.forms | Base order form used widely. |
| Process | “Order Submit (Generic)” | cap.ordering.processes | Shared ordering lifecycle. |
| Catalog record | “SD-WAN Offer” | cap.ordering.sdwan.catalog | SD-WAN-specific commercial and technical attributes. |
| Form / wizard | “SD-WAN Site Setup Wizard” | cap.ordering.sdwan.forms | SD-WAN-specific fields, validations, and UI steps. |
| Process | “SD-WAN Provisioning Orchestration” | cap.ordering.sdwan.processes | Product-specific flow pieces integrated into ordering. |
| Script / rule | “SD-WAN Eligibility Check” | cap.ordering.sdwan.processes (or cap.ordering.sdwan) | Kept with the domain where it is primarily maintained. |
| Register | “SD-WAN Device Models” | cap.ordering.sdwan.catalog | Product-specific reference data for catalog and ordering. |
This structure keeps:
- Ordering fundamentals centralized under
cap.ordering.* - SD-WAN specifics isolated under
cap.ordering.sdwan.*, with clear ownership and a clean navigation scope
Renaming and stability
ConfigType codes are used in references, filters, and tooling; changing them can break references and selections.
Because all configuration entities store the owning package code in their configType property, renaming a ConfigType can have a large impact across all configuration that belongs to it (and all descendants, if renamed). The system will attempt to re-link affected configuration items, but renames should be performed very carefully, with full awareness of the scope of impacted assets.
Elasticsearch representation
To support fast cross-entity navigation, search, quick preview, impact analysis, and package-aware administration, tSM maintains an Elasticsearch read model for configuration items grouped by ConfigType.
This index is designed as a generic projection across configuration entity types. It is populated asynchronously from entity Kafka topics. At runtime, tSM resolves the current list of entity types and their associated topics, listens for changes, and updates the shared Elasticsearch index without requiring a hardcoded list of supported configuration entities at development time.
Purpose of the Elasticsearch index
The Elasticsearch projection is the preferred source for:
- searching configuration items under a ConfigType subtree
- quickly listing all items belonging to a ConfigType
- grouping results by entity type or microservice
- showing quick item previews without loading every source API separately
- evaluating impact before package/export/restore operations
- surfacing package installation and drift signals together with the current configuration item
The Elasticsearch projection is a read model only. The authoritative source of configuration remains the owning microservice and its underlying database.
Common information indexed for each configuration item
Each indexed configuration item stores a common set of fields independent of the original entity type.
| Field | Type | Description |
|---|---|---|
entityId | String | Stable identifier of the configuration item. |
entityType | String | Source entity type (for example Form, Process, Register, NotificationRule). |
entityCode | String | Human-friendly code of the item, if available. |
name | String | Human-friendly name of the item, if available. |
description | String | Description of the item, if available. |
configType | String | Owning ConfigType code of the item. |
configTypePath | List | Full ConfigType ancestry used for subtree search and filtering. |
microservice | String | Owning microservice of the item. |
validityFrom/To | Date | Validity window of the item, when available. |
dataTags | List | Searchable labels/tags on the item. |
whoInserted | String | Audit signal from the source entity. |
whenInserted | Date | Audit signal from the source entity. |
whoEdited | String | Audit signal from the source entity. |
whenEdited | Date | Last edit timestamp from the source entity. |
lastUpdated | Date | Timestamp when the Elasticsearch projection was last refreshed. |
custom | Object | Optional extended data for entity-specific search and UI use. |
ConfigType-aware search and filtering
Because the index stores both configType and configTypePath, users can:
- search for items in one exact ConfigType
- search all items under a ConfigType subtree
- aggregate results by entity type, owner microservice, or tags
- combine ConfigType filtering with free-text search and package signals
This is especially important in large installations where a single functional area can contain many different entity types spread across several microservices.
Relationship to source entities
The Elasticsearch document is intentionally normalized and lightweight:
- it contains enough information for search, filtering, and quick view
- it may embed selected item-specific attributes in
custom - it does not replace the full source entity representation
When detailed editing or authoritative comparison is required, the user continues to work with the owning API or configuration screen of the original entity.
Installed Package signals in Elasticsearch
ConfigType-based administration is often used together with package operations. For this reason, the Elasticsearch projection can also expose selected information derived from Installed Package tracking.
See also: Installed Package
The goal is to let users answer questions such as:
- Which package most recently installed this item?
- Was this item modified after installation?
- Is the current item drifted compared to what the package installed?
- Which ConfigType subtree contains changed or missing package-managed items?
Package-related fields available in the index
| Field | Type | Description |
|---|---|---|
latestInstalledPackage.packageId | String | Identifier of the most recent package that installed the item. |
latestInstalledPackage.packageName | String | Display name captured from the latest installation record. |
latestInstalledPackage.version | String | Latest installed package version for this item. |
latestInstalledPackage.installedAt | DateTime | Timestamp of the latest installation affecting the item. |
latestInstalledPackage.installedBy | String | User/service that performed the latest installation. |
latestInstalledPackage.installSource | Enum | Origin of the latest installation, if tracked. |
packageStatus.compareStatus | Enum | Current drift evaluation for the item (UNCHANGED, CHANGED, MISSING, UNKNOWN). |
packageStatus.modifiedAfterInstall | Bool | Fast timestamp-based signal that the item was modified after its latest installation. |
packageStatus.sourceModifiedAt | DateTime | Source timestamp captured at install time, if available. |
packageStatus.currentModifiedAt | DateTime | Current observed modification timestamp of the item. |
packageHistory | List | Optional compact history of package versions that contained the item. |
Why package data is projected into the ConfigType index
Adding Installed Package signals to the same ConfigType-centric search index makes it possible to:
- locate all changed package-managed items under a ConfigType subtree
- identify which ConfigType areas were affected by a package installation
- quickly inspect whether a configuration item is still aligned with the package that installed it
- support package-aware filtering, export, validation, and impact analysis without loading package and configuration data separately
Typical examples
Examples of useful searches supported by the index:
- all items under
cap.ordering.*changed after their latest package installation - all
Formitems incap.ordering.sdwan.*installed by packageSDWAN - all items with
compareStatus = CHANGEDgrouped by ConfigType and entity type - all package-managed items belonging to a selected capability before export or restore